深入剖析IIS 6.0（下)
　　前文介紹了IIS 6.0的安裝和Web伺服器的新型體系結構。IIS 6.0新特性的數量多得令人驚奇，其中一些特性是如此引人注目，以至於人們的大部分注意力都被它們吸引。在這第二篇介 紹IIS 6.0的文章中，我們不僅將瞭解這些已成為“明星”的特性，還將關注一下IIS 6.0各種較少有人注意卻同樣重要的改進之處。
　　一、安全
　　微軟一次又一次地做著同樣一件事情——某個軟體產品出了問題，飽受人們詬病，於是趕緊發佈新的版本將問題解決。例如，發佈Windows NT 4.0之後，因穩定性問題而飽受批評；於是微軟發佈了Windows 2000，新作業系統的穩定性頗受好評，但Win 2K伺服器默認安裝的IIS 5.0卻成了巨大的安全隱患，需要下大力氣加以整治才能解決問題。IIS 6.0默認不安裝，如果按照缺省方式安裝，Web伺服器只能提供靜態內容服務。因此，從這個角度看，即使以後IIS 6.0應用引擎和元件突然出現了問題，IIS 6.0還是極大地降低了安全風險。另外，Windows Server 2003還有一個新的組策略“禁止安裝IIS”，有了該組策略，我們就可以禁止Windows 2003在活動目錄（AD）森林中禁止不準備作Web伺服器用的機器上安裝IIS 6.0，防止網路上出現根本無用的、不安全的IIS 6.0伺服器。不過，目前這個組策略只對Windows 2003伺服器有效，不能防止Windows XP Pro和Win 2K的機器安裝IIS 5.0。
　　當然，由於剛剛安裝好的IIS 6.0不支援動態內容，所以出現了第二個人們經常會問的問題：“為什麼我的伺服器不能運行ASP？”（前文提到，第一個人們經常會問的問題是：“IIS 6.0可以在Win 2K伺服器上運行嗎”？答案是“不”）。要想在IIS 6.0上運行程式，必須使用IIS 6.0的一種新特性，即Web服務擴展，或Web Service Extension（這個名字似乎意味著它與XML Web服務有某種關係，實際情況並非如此。）

　　如果要為某個程式啟用Web服務擴展，首先打開IIS管理器（在“控制面板”→“管理工具”中。以前叫做Internet服務管理器或ISM），如圖一，點擊“添加一個新的Web服務擴展”，啟動嚮導創建一個新的規則。為規則指定一個名字，然後找到想要啟用的執行檔。另外，\system32\inetsrv下有一個iisext.vbs腳本，它也能夠配置並管理運行帶有IIS 6.0的Windows Server 2003的Web服務擴展、應用程式和單獨的檔。管理員可以使用此腳本來啟用和列出應用程式；添加和刪除應用程式依賴性；啟用、禁用和列出 Web 服務擴展；添加、刪除、啟用、禁用和列出單獨檔。


圖一
　　在圖一中，注意“所有未知ISAPI擴展”和“所有未知CGI擴展”這兩種Web服務擴展。默認情況下，這兩種擴展是禁用的，意味著除非明確地允許一個應用在IIS 6.0上運行，否則它就不能運行。如果一個用戶請求了某個沒有啟用的檔，IIS 6.0將向用戶返回404錯誤——檔或目錄沒有找到，同時在W3SVC日誌中記錄“ 
404.2檔或目錄無法找到：鎖定策略禁止該請求”。在IIS 6.0中，404.2和其他子狀態代碼是W3SVC日誌檔的一項可選功能，用來幫助排解故障、疑難（IIS 5.0和IIS 4.0中也有子狀態代碼，不過不會在日誌檔中記錄，但可以將它們轉到定制的錯誤頁面，便於根據子狀態代碼執行特殊的處理）。IIS 6.0的子狀態代碼很有用，它們提供了描述問題的詳細資訊，例如：403.20，禁止訪問：Passport登錄失敗；403.18，禁止訪問：無法在當前應用程式池中執行請求的URL；404.3，檔或目錄無法找到：MIME映射策略禁止該請求；500.19，伺服器錯誤：該檔的資料在配置資料庫中配置不正確。所有這些錯誤和其他錯誤都映射到定制的錯誤頁面，錯誤頁面不會把子狀態代碼發送給用戶，攻擊者無法獲知具體的錯誤資訊。
　　另一個安全方面的改進之處是IIS 6.0允許指派一個加密服務提供者（Cryptographic Service Provider，CSP），能夠將基於硬體的安全套接字層（SSL）加速器集成到IIS 6.0，從而把加密任務從伺服器的通用CPU轉移到了專門為加密操作而優化的專用設備，有利於提高性能和可靠性。
　　二、配置資料
　　在IIS 5.0和IIS 4.0中，配置資料庫採用二進位檔結構，但IIS 6.0放棄了這一做法。IIS 6.0的配置資料由兩個XML檔構成：一個是Metabase.xml，包含IIS 6.0伺服器的配置資訊；另一個是mbschema.xml，包含配置資料的模式定義。IIS管理器提供了一項新的功能，允許保存配置資料副本，只要右擊Web網站，然後選擇“所有任務”→“將配置保存到一個檔”，然後指定配置資料副本的檔案名字和保存路徑即可。按照這種方式保存配置資料時，IIS 6.0利用系統的機器碼（Machine Key）加密配置資料的某些部分，因此，配置資料的副本只對創建該副本的機器有用。
　　不過，在“將配置保存到一個檔”對話方塊中，我們可以選中“用密碼對配置進行加密”選項，然後指定密碼，用密碼來保護導出的配置檔。如果提供了密碼，IIS 6.0將用密碼來替代機器碼，以後只要提供同一個密碼，就可以將配置資料導入到另一個伺服器。另外，我們可以使用命令行腳本iisback.vbs（在systemroot\System32中）創建和管理遠端或本地電腦的IIS配置的備份副本，管理員可以使用此腳本工具創建其IIS配置的備份副本，從備份副本還原IIS配置以及列出和刪除備份副本。
　　有些時候，我們只要保存某個應用程式池、Web網站或虛擬目錄的配置，而不是保存全部的配置資訊，這時可以按照如下步驟操作：右擊要保持配置資訊的物件，選擇功能表“所有任務”→“將配置保存到一個檔”，如圖二所示，如果準備將配置資料導入到另一個伺服器，必須提供加密檔的密碼。

圖二

　　如果右擊一個應用程式池、Web網站組或單個網站，然後選擇“新建”→“應用程式池（來自檔）”，或者“新建”→“網站”→“來自文件”，或者“新建”→“虛擬目錄（來自檔）”，就可以從保存的配置檔創建新的應用程式池、Web網站或虛擬目錄。因此，必要的時候，我們可以只創建和配置一個物件，利用“將配置保存到一個檔”功能導出物件 
的配置資訊，然後利用“新建”→“虛擬目錄（來自檔）”等功能將配置資訊導入到多個Web網站。這就是說，我們可以先精心配置一個範本，然後用它來創建和配置新的網站。當然，出現問題時，配置資訊副本還可以用來恢復網站的設置。
　　由於IIS 6.0配置資訊是可移植的，它還有另外一個好處，這就是方便了升級。假設我們升級時不能直接在Win 2K/IIS 5.0上安裝Windows 2003/IIS 6.0，必須換一台機器，這時就要解決如何將IIS 5.0不可移植的配置資料轉移到新的IIS 6.0伺服器的問題。利用IIS 6.0配置資料的可攜性，解決辦法是：首先安裝好新的Windows 2003伺服器，為原來的Win 2K伺服器做一個完整的備份，然後在Win 2K伺服器上安裝第二個Windows 2003伺服器將它升級，導出第二個Windows 2003伺服器的配置資料（用密碼加密），然後將配置資料導入到新的Windows 2003伺服器。新安裝的Windows 2003伺服器必須作一些調整，例如允許IUSR帳戶等，但至少現在不必重新執行全部配置操作了。
　　IIS 6.0的配置資料是標準的文字檔案（XML檔），所以可以用記事本之類的文本編輯器打開和編輯。如果修改了IIS 5.0或IIS 4.0的配置資料，有時必須重新啟動IIS，如果系統上網站的數量很多，可能需要不少時間，例如ISP的伺服器就屬於這類情況。為了解決這個問題，IIS 6.0支援一種“運行時允許編輯”功能。“運行時允許編輯”功能按照如下方式啟用：在IIS管理器中，右擊伺服器，選擇功能表“屬性”，然後選中“允許直接編輯配置資料庫”選項，如圖三所示。啟用了這個功能之後，如果我們用記事本打開配置資料檔案，插入一個虛擬目錄的配置，然後保存並關閉配置檔，IIS 6.0幾乎立即就能根據配置檔的設置作相應的修改，根本無需重新啟動。

圖三
　　既然允許直接編輯配置檔，因配置檔不合法造成的伺服器、應用程式故障也必然增多。為此，IIS 6.0提供了配置檔歷史版本目錄，即\system32\inetsrv\history，每次修改配置資料或重新啟動IIS 6.0，IIS 6.0都會在該目錄中保存一份原有的配置資料。
　　三、IIS管理器
　　每次產品重大升級，人們都會試圖從用戶介面尋找令人激動的新功能。IIS 6.0的管理器確實有了變化，不過改動之處出乎意料地少。
　　其中一個改動之處雖小，但很實用。如果在IIS管理器中右擊一個檔夾，現在可以選擇“許可權”功能表打開檔夾的“安全”對話方塊。在這個對話 
框中可以設置檔夾的NTFS授權，不必再離開IIS管理器。雖然這是一個小小的改動，也許它今年會為全世界所有的IIS管理員總共節省數千小時的工作時間。
　　右擊一個Web網站，選擇“屬性”，轉到“目錄安全性”頁，點擊“安全通信”下面的“編輯”按鈕，在這裏可以找到另一個重要的改動之處——安全通信屬性頁允許配置SSL、證書信任列表（CTL）、客戶證書。在IIS 5.0和IIS 4.0中，除非在Web網站上安裝一個證書，否則不能訪問該屬性頁，這一限制令人不快，因為從技術上看，配置CTL、客戶證書並不要求伺服器上安裝了證書，換句話說，在IIS 5.0中我們安裝證書的唯一用途可能就是因為用戶介面需要它。IIS 6.0改正了這一多餘的要求，現在我們不必在Web伺服器上安裝證書也可以訪問和使用該屬性頁了。
　　四、通配符應用程式
　　如果你熟悉IIS 5.0和IIS 4.0的ISAPI篩選器，可能也熟悉它們的缺點。ISAPI篩選器不僅編寫困難，而且由於它們在Inetinfo進程內運行，如果編寫時不小心留下了一點錯誤，很容易導致災難性的後果，出錯的代碼可能造成整個IIS崩潰。另外，ISAPI篩選器不能擁有常規ISAPI DLL擁有的功能。當然，不管怎樣，在IIS 5.0和IIS 4.0中，ISAPI篩選器仍是一種非常有用的元件，是唯一可以針對所有進入Web伺服器或Web網站的請求執行操作的代碼。
　　IIS 6.0提供了一種更加靈活的新型機制來提供通常由ISAPI篩選器提供的服務，它就是ISAPI截取器（Interceptor），或者稱為通配符應用程式（Wildcard Application）。通配符應用程式的配置方式是：在IIS管理器中右擊Web網站，選擇功能表“屬性”，轉到“主目錄”頁面，點擊“應用程式設置”下面的“配置”按鈕，出現“應用程式配置”對話方塊，如圖四所示。在對話方塊的“映射”頁中，我們可以將一個或多個ISAPI DLL配置成通配符應用程式。對於每一個接收到的請求，IIS 6.0將調用這裏列出的各個通配符應用程式。除了針對所有網站配置通配符應用程式，還可以針對單個網站或在目錄層次上配置通配符應用程式。由於這些ISAPI截取器是標準的ISAPI應用程式，它們具有普通ISAPI應用程式具備的所有功能，包括訪問訊息文字的能力，而不僅僅象ISAPI篩選器那樣訪問消息頭。

圖四
　　通配符應用程式可以做到開發者要做的任何事情，諸如URL定制、驗證身份、記錄特殊的日誌資訊、檢測攻擊企圖、創建內容，等等。通配符應用程式結束處理後，它把請求轉交給適當的處理引擎（例如處理ASP頁面的asp.dll），由處理引擎進一步處理請求。另外，通配符應用程式還可以通過調用為ISAPI應用程式新增的ExecuteURL功能 
，將請求傳遞到同一個應用程式池中的任意頁面。
　　新增的ISAPI通配符應用程式為創造性的應用程式設計大開方便之門。例如，IIS 6.0的URL授權功能就是作為一個ISAPI通配符應用程式（urlauth.dll）實現。URL授權功能允許IIS 6.0根據一系列的規則授予對某個URL的訪問權，例如用戶是否為某個組的成員、地理位置，以及其他在資料庫或AD中與用戶有關的資訊。有關ISAPI通配符應用程式和URL授權的更多資訊，請參見IIS 6.0的説明文檔。
　　五、日誌功能
　　伺服器的日誌功能很少成為首要的關注物件，但卻是日復一日的伺服器管理和監視工作不可或缺的助手。IIS 6.0在日誌功能方面有許多重大的改進，但遺憾的是，W3SVC日誌事件仍不能以本地時間記錄。
　　在IIS 6.0中，記錄日誌的功能已經改為由http.sys實現，http.sys在內核模式下運行。這一改進加快了日誌寫入速度，同時避免了多個工作進程爭用同一日誌檔。某些特殊的情況下，http.sys會遇到錯誤，這時它應該但卻不能將日誌資訊寫入Web網站的日誌，例如，工作進程正在被回收，禁止http.sys處理用戶請求，或者用戶試圖連接到伺服器，但請求中只提供了IIS所需資訊的一部分。如果出現這類情況，http.sys將把事件寫入一個新的日誌檔httperr.log。
　　在排解故障、優化IIS 6.0的過程中，httperr.log日誌檔是十分重要的。默認情況下，httperr.log檔保存在\system32\logfiles目錄，但可以修改，修改方法是找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters註冊子鍵，在它下面添加一個名為ErrorLoggingDir的字串值，在ErrorLoggingDir中設置保存日誌檔的完整路徑。在httperr.log日誌檔中可以找到的資訊包括：所有的503（服務不可用）錯誤，空閒連接超時，解析URL時出現的各種錯誤，最後10個提交給失敗的應用程式池的請求。
　　IIS 6.0還擁有一種稱為二進位日誌的功能，啟用這個功能後，IIS 6.0將把Web網站的所有日誌資訊寫入一個二進位格式的日誌檔，日誌檔的副檔名是.ibl。要啟用二進位日誌功能，只要把配置檔的W3SVCC/CentralBinaryLoggingEnabled條目設置成ture（1）即可。對於ISP來說，這個功能應該非常有用。ISP的每台機器上可能有1000甚至更多的Web網站，如果每個Web網站每天生成一個日誌檔，日誌檔的總數很快會達到一個天文數字。微軟最近發佈的Log Parser 2.0工具能夠讀取二進位日誌檔並生成報告，這個工具可以從http://download.microsoft.com/download/iis50/utility/2.0/nt5xp/en-us/setup.exe下載。Log Parser 2.0還能夠讀取前面介紹的httperr.log文件並生成報告。
　　從很久以前開始，IIS就允許指定本端伺服器上保存日誌檔的目錄了。不過，雖然IIS 5.0和IIS 4.0的IIS管理器允許在指定日誌檔路徑的時候輸入一個遠端伺服器的通用命名規範（UNC）的路徑，但Web伺服器實際上不會把日誌保存到遠端伺服器。只有IIS 6.0才真正支援日誌檔路徑的UNC路徑名。
　　六、網站ID
　　對於IIS伺服器來說，唯一標識一個網站的不是網站的名稱，而是網站的ID數值。當我們在IIS 5.0和IIS 4.0中創建一個新的網站，Web伺服器將下一個可用的數位順序號指定給網站（即，Web伺服器給默認站點指定的數字是1，下一個網站是2，接下來是2、3、4，等等），這個數 
字就是網站的唯一ID。如果要訪問一個網站的日誌檔，首先必須知道該網站的ID，因為日誌檔保存在\W3SVC\<網站的ID編號>目錄。如果Web伺服器上運行著一個以上的網站，僅僅依靠日誌檔的路徑名稱根本無法判斷哪一個日誌目錄屬於哪一個網站。另外，無論是在編寫管理腳本時，還是在修改配置資料檔案時，網站ID都是必不可少的，例如，在IIS配置資料檔案中指定ADSI（活動目錄服務介面，Active Directory Service Interface）路徑時往往要指定正確的網站ID。
　　儘管如此，在IIS 5.0和IIS 4.0中，從IIS管理器無法直接找到網站的ID編號。為此，IIS 6.0的管理器在網站清單中增加了一個新的“識別字”列，該列的內容就是網站的ID編號。不過，即使IIS 6.0 Web伺服器上只有二三個網站，網站的ID也可能很大，例如387660891（因此該網站的日誌檔路徑是\W3SVC\387660891），不必奇怪，IIS 6.0不再按照順序指定網站的ID了——它根據網站的名字計算出網站的ID。
　　如果你編寫了一些腳本程式輔助管理，這些腳本要求使用原有的網站ID順序生成方式，可以禁用IIS 6.0新式的ID生成方式，具體的操作步驟是：找到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetMgr\Parameters註冊子鍵，創建一個REG_DWORD值IncrementalSiteIDCreation，將它設置為2（注意，默認情況下，該鍵不存在）。
　　七、非同步CGI處理
　　IIS 5.0和IIS 4.0以同步方式運行CGI（Common Gateway Interface，通用閘道介面）進程，這實際上意味著每次只有一個線程能夠訪問一個CGI進程，所以IIS 5.0和IIS 4.0對CGI支持的可伸縮性不佳。IIS 6.0能夠非同步運行CGI進程，所以如果一個線程調用了一個CGI應用程式，它不必再等待CGI進程處理完畢和返回資訊。非同步CGI改善了IIS伺服器運行CGI Web應用程式的性能，使得IIS能夠運行更多執行關鍵任務的基於CGI的應用程式。
　　當Web伺服器接收到包含CGI程式名和程式所需參數的URL時，CGI程式開始執行。如果將CGI程式編譯為可執行 （.exe）檔，則必須提供包含程式執行許可權的目錄，以便用戶可以運行程式。如果CGI程式以腳本形式（例如Perl腳本）編寫，則既可為目錄提供執行許可權，也可為其提供腳本許可權。另外，如果要使用腳本許可權，必須將腳本解釋程式標記為腳本引擎。
　　必須注意的是，默認情況下，IIS_WPG組不具備啟動CGI進程的許可權。如果創建了新帳戶並將其添加到IIS_WPG組，還必須授予此帳戶兩種啟動CGI進程的用戶許可權，即“調整進程的記憶體配額”和“替換進程級權杖”。
　　八、帶寬限制
　　在IIS 5.0和IIS 4.0中，Web網站屬性對話方塊的“性能”頁允許啟用帶寬限制功能，指定允許網站佔用的最大帶寬。不過，這個功能不一定起作用，因為IIS 5.0和IIS 4.0不能直接操作伺服器的網卡。
　　IIS 6.0則不同，第一次啟用帶寬限制功能時，Windows 2003自動安裝QoS資料包計畫程式供IIS伺服器調用。QoS資料包計畫程式使得伺服器能夠控制服務品質（即QoS），因此安裝期間Windows 2003將臨時地停止所有網路服務。配置好QoS資料包計畫程式後，IIS才真正有了擔負起控制網站帶寬限制所需的驅動程式——對於ISP來說，這無疑是一個好消息。允許設置的最小帶寬限制值是1024 Byte/秒。不要忘了檢查一下網卡是否在Windows 2003硬體相容清單（HCL）中，因為只有最新的網卡才支援QoS功能。
　　要配置QoS資料包計畫程式，首先必須創建一個組策略控制臺。點擊“開始”→“運行”，輸入“mmc”，然後點擊“確定”。在控制臺視窗中，選擇功能表“檔”→“添加/刪除管理單元”，點擊“添加”，在“添加獨立管理單元”對話方塊中，選擇“組策略物件編輯器”，然後依次點擊“添加”、“完成”、“關閉”、“確定”。現在依次擴展控制臺中的“本 
地電腦策略”、“電腦配置”、“管理範本”、“網路”，顯示出“QoS資料包計畫程式”，如圖五所示。

圖五
　　啟用帶寬限制之前，請使用系統監視器檢查“網路介面”物件中的總位元組數/秒或當前帶寬計數器。如果希望比較傳入和傳出流量，請檢查發送的位元組數/秒和接收的位元組數/秒，再比較“網路介面”物件的值和網路連接的總帶寬。對於“正常”的負載，伺服器使用的帶寬不應超過其全部可用帶寬的50%。如果伺服器有較大的高峰負載，請將正常負載保持在50%以下，剩下的帶寬可在高峰期使用。
　　帶寬限制可以是針對全局WWW服務的（即對所有網站都有效），也可以是針對單個網站的。設置全局WWW服務最大帶寬不會替代已為伺服器上的單個網站設定的最大帶寬。單個站點根據已設置的最大值來限制帶寬，而全局設置限制所有其他未限制帶寬的網站。另外，全局WWW服務帶寬限制設置不會影響FTP站點或FTP服務。
　　九、默認設置的變化
　　在IIS 6.0中，許多配置專案的預設值已經與IIS 5.0或IIS 4.0的不同。例如，默認的連接超時時間已經從900秒減少到120秒，另外，EnableParentPaths設置默認關閉。還有其他一些新的設置項目也會影響伺服器的性能和行為，包括：
　　⑴ 如果某種檔類型沒有在MimeMap配置屬性中映射，所有對該類檔的請求將被拒絕。
　　⑵ 默認情況下，所有工作進程會在1740分鐘後自動回收，回收期間會話資訊可能丟失。
　　⑶ 運行CGI應用程式的用戶上下文必須是一個IIS_WPG組的成員。
　　⑷ Windows 2003不安裝Collaboration Data Objects for Windows NT Server（CDONTS）。微軟建議開發者改用CDO for Windows 2000（CDOSYS）對象。
　　⑸ ASP請求默認限制在204800位元組之下，每一個域限制在100 KB之下。IIS 5.0和IIS 4.0沒有這方面的限制。
　　⑹ 默認情況下，http.sys僅接受標題小於16 KB的請求。
　　本文關於IIS 6.0的介紹就到這裏結束，雖然文章很長，但還是不可能做到面面俱到，例如，還沒有提及受到廣泛關注的Passport驗證和摘要驗證方面的改進，本文的重點放在一些具有突破性意義的IIS 6.0新特性以及幾種較少有人提及的功能，以此證明IIS 6.0改進的廣泛性、深入性。從許多方面來看，IIS 6.0的風頭甚至蓋過了Windows 2003——而且許多人認為，IIS 6.0確實有資格佔據舞臺的中央。

 

文章來自: Tank部落格
引用通告: 查看所有引用 | 我要引用此文章
Tags:
相關日誌: